1. Technical Field
The present invention relates generally to modular computer systems and specifically to inter-object communication for hardware and software modules in a modular computer system environment. Still more particularly, the present invention relates to a method and system for implementing a publish/subscribe communication framework for inter-object communication among hardware and software modules in a modular computer system environment.
2. Description of the Related Art
The technology for implementing a dynamic, modular computing environment is rapidly evolving. Modular computer systems include a number of independent modules that are connected to and communicate with other modules within the system via some point-to-point communication mechanism. Unlike large-scale distributed computer systems (e.g., the Internet), the modules are not independent processing systems or computing devices, but are rather software applications or code that perform specific functions within the overall system environment. Additionally, the hardware components of the modular computer systems may be simple hardware instrumentation that provides input data or serves as an output device.
Typically, the modular computer system is configured with the modules being local to a processor and connected to a single computer chassis. With this configuration, specific functions can be performed by the system based on the individual applications, and additional functions can be added to the system as required/desired. Those skilled in the art are familiar with such modular computer systems and their level of expandability and/or scalability.
One example of a modular computer system is the computer system designed for modem motor vehicles. Several different types of functions are provided by different instrumentation and/or software modules, including regulating temperature, tire pressure, exhaust/fuel emissions, providing emergency services, and other general safety features. These functions require some type of interaction (e.g., sharing of data) between hardware instrumentation and software application/modules. One quickly evolving and popular function is that of providing vehicle location and navigation functionality, such as is provided utilizing global positioning system (GPS) technology.
In both the distributed computing environment and the modular computing environment, it is essential that the different components be able to exchange data effectively. However, because of the above mentioned difficulties with the point-to-point connection model, there remains a lack of full integration among all modules and hence an inability to effectively manage communication among the increasingly integrated (modular) systems.
Irrespective of the use of the system, the various programming modules, whether actual computer devices, other input/output (I/O) hardware devices, or application code, need to communicate with each other and/or at least with the operating system in a language/form that is understandable to the communicating devices. Most conventional applications connect and communicate with other modules via a point-to-point connection architecture. With this point-to-point architecture, each application has a unique set of parameters, values and formats for communicating with one of the other modules in order to provide a particular service/function.
FIGS. 5A-5C provide three representations of modular computer system operation according to the prior art. As illustrated by FIG. 5A, modular computer system 500 comprises three hardware components, a GPS device 501, temperature reader 503, and generic other device 505. Each component has a point-to-point connection to one or more of the other components, as indicated by the direct wire connections. Also, each device has an associated (first-in first-out) FIFO queue, GPS queue 502, temp queue 504, and other queue 506. The queues serve to marshal request for respective data received from one or more modules, called MOD1 511, MOD2 513, X-STAR program 515, and MODN 517. Each module issues a request for a value provided by one or more of the hardware components. The requests are queued based on order of receipt and the return data provided in the queued order. FIGS. 5B and 5C respectively illustrate the modules sending a request to the queues of the GPS tracker 501 and temperature reader 503. Notably, only a single request can be handled at a time, and all other requests must wait in the queue until the previous request has been handled.
Developers and/or manufacturers of new applications for modular computer systems tend to develop each application/module with a specific set of communication protocols that enables the module to communicate with only specific ones of the other modules in the modular computer system. A new module is connected directly (point-to-point) with another module and may only be able to communicate with that other module among the multiple modules provided within the system. Because it is common for the different modules to be developed by different manufacturers/developers, it is also very common for each module to have a module-specific communication protocol that is not necessarily understood or easily adaptable to the other modules designed by other manufacturers and/or for other systems. That is, a software module designed to operate with a first GPS system may not be able to communicate directly with a second, different GPS system that may be utilized in the same or other modular computer system.
To overcome this limitation (i.e., incompatibility among modules), manufacturers often develop the new module and then create a separate application to enable their module to communicate within a particular system. These specialized applications may be required to link the new module to the existing ones. That is, a different application may be required for each additional system in which the module may be utilized. FIGS. 5B and 5C illustrate this implementation of separate inter-module communication applications. Mainly, MOD1 and MOD2 communicate with GPS tracker 501 via a first set of request and response pairs 521A, 521B and 523A, 523B. According to the illustration, each module has a unique method of communicating with GPS tracker 501. Similarly also, is the intercommunication between the modules and temperature reader 503. Specific application code/parameters for a second set of request and response pairs 531A, 531B and 533A, 533B are provided, which may be different from those used for communicating with GPS tracker 501.
While the above methods have enabled and fostered the implementation of systems in which independently developed applications can operate and communicate within the same system. These objects can only be integrated within the system by writing specific code to tie independently developed applications together. This method is rather tedious and costly for very complex systems comprising a large number of interconnected devices and applications.
Many systems today utilize a listener pattern for integration. The listener pattern allows for objects to register interest in receiving events relevant to another object. The listener pattern requires compile time interface coupling between the event source and listeners, and the listener pattern is sensitive to bugs within the listeners. Further, utilizing the listener pattern has several additional drawbacks. Key among these drawbacks is that if the listener pattern is coded without a notification thread and queue, then each listener has the opportunity to sabotage the thread that is performing the notification by taking to long to return from the notification call. This means that to ensure that the lower level buffers are not overrun, each listener must not only be logically correct, but must also be temporally correct.
In the automobile computing environment, for example, there are several problems with conventional implementation of modular computer systems that utilize the listener pattern makes it difficult for connecting the individual application modules together. With the listener pattern, if five different applications require access to a parameter value, such as the GPS position, each application had to independently listen to the GPS device. Several problems are seen with this model. First, the modules require a point-to-point configuration. Second, only very basic (wildcard type) requests can be submitted, and matching just the basic request automatically returns the data without the ability to target specific characteristics within the system. Third, as with the example above, the applications have a compile time dependency on the GPS code.
Given the above limitations of the listener pattern and other complexities with effective inter-communication among individual application modules in a modular computer system, it would be desirable to provide a method and system that enables efficient inter-communication among the various application modules in a modular computer system environment that was more robust and comprehensive than the listener pattern. It would further be desirable if such a system enabled all modules to have equal, concurrent access to all published data of relevance within the system. A method and system that provides intercommunication among all components within an expandable modular environment utilizing without requiring special integration code for each application would be a welcomed improvement. These and other benefits are provided by the invention described herein.